home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 4629 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.3 KB  |  82 lines
  1. Newsgroups: comp.lang.c++
  2. Path: cix.compulink.co.uk!usenet
  3. From: alexbrn@cix.compulink.co.uk ("Alexander Brown")
  4. Subject: Object type v object mode
  5. Message-ID: <DM1JIv.25A@cix.compulink.co.uk>
  6. Organization: Compulink Information eXchange
  7. Date: Wed, 31 Jan 1996 10:23:18 GMT
  8. X-News-Software: Ameol
  9.  
  10.  
  11. I'm trying to devise some guidelines for myself on when it's appropriate 
  12. to model different behaviours of something being modelled by having many 
  13. multiple types, when by having different "modes" of behaviour in a 
  14. smaller number of types.
  15.  
  16. For example, consider an animation class that inherits from a container 
  17. containing animation frames. The class has Play and Stop methods which 
  18. control the animation, and inherits methods like Add and Remove from the 
  19. container, for editing its frame sequence.
  20.  
  21. Now, let's say the animation class should also be able to play in 
  22. reverse. To add this functionality we _could_ design multiple types
  23.  
  24.                                 
  25.                               / ForwardAnimation
  26. container ---- AbstAnimation /
  27.                              \
  28.                               \ ReverseAnimation
  29.                                
  30. AbstAnimation might have a pure virtual method Play which was implemented 
  31. in the subclasses to provide forwards or reverse playback as appropriate.
  32.  
  33. I'd guess however that nobody would want to do it this way (?), but would 
  34. instead add a data member to the single Animation class together with 
  35. methods like SetDirection and GetDirection which would allow the object's 
  36. user to control replay direction.
  37.  
  38. Okay, now let's say we also want to have the ability to have read-only 
  39. animations -- they're passed a file spec in their constructor, and if 
  40. they load their frame sequence successfully, they can be played and 
  41. stopped, but not edited.
  42.  
  43. Again we're faced with the same choice: make new types (e.g., 
  44. ReadOnlyAnimation and EditableAnimation) or add a data member to the 
  45. animation class which allows the object's user to set a read-only mode.
  46.  
  47. If we take the former approach, the ReadOnlyAnimation class could use 
  48. private or protected inheritance of the container to hide the container's 
  49. methods like Add and Remove, since these would not make sense in a 
  50. read-only animation.
  51.  
  52. In the latter approach - of adding a new read-only "mode" to our 
  53. Animation class - the problem arises: what to do when the class's Add or 
  54. Remove methods are called? throw an exception?
  55.  
  56. (Another approach might be  a class relationship like:
  57.  
  58. container ---[private inh]--- ReadOnlyAnimation ---[pub. inh]--- Animation
  59.  
  60. with the final Animation class exposing some of the container's methods 
  61. by calling them through.
  62.  
  63. Another might be to use a notion of constness?)
  64.  
  65. Anyhow, my question at the end of all this is: _when_ to represent 
  66. different behaviour by a different type, and _when_ by a different "mode"?
  67.  
  68. Either extreme would be bad. Too many types would lead to an 
  69. over-dispersed object model (IMO). Too many "modes" would move us away 
  70. from OO towards having procedural programming dressed-up as classes.
  71.  
  72. As a working rule of thumb I think that a class can have "modes" so long 
  73. as all of its services remain reconcilable with each mode.
  74.  
  75. What do other people think ?
  76.  
  77.  
  78. --
  79. Alex Brown                              |  "I wasted time, and now 
  80. alexbrn@cix.compulink.co.uk             |   time doth waste me."
  81. http://www.compulink.co.uk/~arachne/    |  
  82.